home *** CD-ROM | disk | FTP | other *** search
/ BCI NET / BCI NET Dec 94.iso / archives / programming / blitzbasic / blitz-list200994.lha / blitz-list / 000496_blitz-list-request_Tue Jul 19 16:32:17 1994.msg < prev    next >
Internet Message Format  |  1994-09-20  |  5KB
  1. Received: from iconz.co.nz (iconz.co.nz [202.14.100.2]) by kantti.helsinki.fi (8.6.9/8.6.5) with SMTP id QAA04957 for <blitz-list@helsinki.fi>; Tue, 19 Jul 1994 16:31:47 +0300
  2. Received: (acid@localhost) by iconz.co.nz (8.6.6.Beta6/8.6.6.Beta6) id BAA15689; Wed, 20 Jul 1994 01:27:45 +1200
  3. Date: Wed, 20 Jul 1994 01:21:50 +1200 (NZST)
  4. From: Acid Software <acid@iconz.co.nz>
  5. Subject: Re: Bugs etc, and some display questions
  6. To: Martin Kift <M.H.Kift@swansea.ac.uk>
  7. cc: blitz-list@helsinki.fi
  8. In-Reply-To: <F14C2E6393@CE1.SWAN.AC.UK>
  9. Message-ID: <Pine.3.87.9407200150.A15620-0100000@iconz.co.nz>
  10. MIME-Version: 1.0
  11. Content-Type: TEXT/PLAIN; charset=US-ASCII
  12. X-Status: 
  13. Status: RO
  14.  
  15.  
  16.  
  17. On Tue, 19 Jul 1994, Martin Kift wrote:
  18.  
  19. > > oh god here we go again, another bloody rom, is that the one in CD32, we 
  20. > > have had no problems with cd32 ports of Blitz games so far, perhaps 
  21. > > bigger vwaits between closing files and entering Blitz mode is required?
  22. > 
  23. > No, I don't think the CD32 has 3.1 (I think it has 3.0 with cd 
  24. > extensions). Only the a4000T has 3.1, although kick3.1/wb3.1 has just 
  25. > been released, which is why I'm getting these reports. Bloody 
  26. > annoying I know, in a way, the amiga is getting almost as bad as the 
  27. > pc in terms of compatibilty.
  28.  
  29. Hmmm, ever tried adding sound effects (soundblaster etc.) to a PC game?? 
  30. Still got a bit to go there
  31.  
  32. > 
  33. > > > 2. I cannot find away to force open a pal screen screen when using 
  34. > > > slices, which is important when running on an ntsc system. Eventually 
  35. > > > I'd like to open a proper ntsc screen and support it properly, but in 
  36. > > > the meantime, I'd like to open a pal screen.
  37. > > 
  38. > > This is very tricky if you want to support workbench startup ie 1942 
  39. > > style monitors and take over the system type startups, the switch lib 
  40. > > looks at a location in graphics library to work out NTSC/PAL and hits 
  41. > > slices accordingly, can you not start your program by using an 
  42. > > openscreentags with some sort of pal config, hmm probably not, tell you 
  43. > > what I'll go and fix this problem instead of waffling on...
  44. > 
  45. > Currently, I'm only interested in opening pal or ntsc low res (15khz) 
  46. > screens for my game. As I said, I would love a way of specifying PAL 
  47. > screens in the slice command, although this would only work on all 
  48. > machines if a PAL screen is possible (some old NTSC machines don't 
  49. > support this, but I'm not too bothered with that).
  50. > 
  51. > Actually, I intend to switch over to using the Display library 
  52. > (especially since I hear you used it for SkidMarks), since I remember 
  53. > reading that it supports aga and ecs. Will it will possible to 
  54. > specify PAL screens in the new display library too, that would be 
  55. > excellent!
  56. >
  57. Done, I will add PAL/NTSC flag to display library, bugger pissing around 
  58. with Mark's slice library, gone gone gone
  59.  
  60. > > At present you have to change them in the palette using agapalrgb and 
  61. > > then do a DisplayPalette
  62. > 
  63. > Okay, although is it true that you can only use agapalrgb in amiga 
  64. > mode. I assume palrgb will also work fine. Any chance of a display
  65. > rgb command in future?
  66.  
  67. What? I don't understand why people think you can't use most of the Blitz 
  68. commands in both Blitz and Amiga mode, I mean some think you can't use 
  69. Blitz in Amiga mode, grrr, as for changing colours in copperlists, this 
  70. is darn tricky, due to commodores crap AGA circuitry to change 1 colour 
  71. in 24 bit takes 4 moves so the display library does colour in chunks of 
  72. 32, I wanted to keep palette handling simple but jeeze, the hardware does 
  73. oh so make it difficult old boy.. (sorry just read Liar by Stephen Fry)
  74.  
  75. > 
  76. > > No, coplists do not take up very much memory at all. the great thing 
  77. > > about having them all allocated at the top of your program is that memory 
  78. > > is not fragmented, in skid for example we had all sorts of bitmaps 
  79. > > openning and closing, if you go and allocate a small piece of memory 
  80. > > anywhere between these calls you suddenly find you have not got enough 
  81. > > continuous memory for the big bitmap... hmmm, again sorry about the waffle...
  82. > 
  83. > Ah excellent! And you can waffle all you like, I'm finding it very 
  84. > interesting 8), since the display docs are somewhat brief at the 
  85. > moment.
  86. > 
  87. > Just one more question, if switching displays, say moving from a 
  88. > display based on coplists 0 and 1, to a display based on 2 and 3 (or 
  89. > whatever), do I just call CreateDisplay over and over again when 
  90. > switching. i.e. is there no need to close down the previous display 
  91. > before creating a new one? (I assume not).
  92. >
  93. yes this is completely and utterly correct
  94.  
  95. > > > P.S. Any release dates available for BUM7? Any chances of fixes for 
  96. > > > the debugger (have you considered the possiblity of remote debugging, 
  97. > > > that would be beautiful!!), the sound/caches problem. Thanks.
  98. > > I'm aiming at Saturday
  99. > 
  100. > Great. 8) Any ideas on the UK release date (we tend to lag behind 
  101. > sometimes)
  102.  
  103. Hmm, UK should be swift this time, the French man is in India finding his 
  104. true self and the boys at Doncaster seem to be relatively organised, part 
  105. time Blitz User running support office will hopefully be in place within 
  106. next 3 weeks
  107.